ระบบคอมพิวเตอร์: มุมมองของนักพัฒนา (ฉบับโลก): ประเภทของการประมวลผลพร้อมกัน: กระบวนการ, การจัดการอินพุต/เอาต์พุตแบบหลายช่องทาง และ เธรด

ในโลกของระบบคอมพิวเตอร์, การประมวลผลพร้อมกันระดับแอปพลิเคชัน คือการวางทับซ้อนกันอย่างตั้งใจของลำดับการควบคุมเชิงตรรกะเพื่อเพิ่มประสิทธิภาพและความไวในการตอบสนอง มันเป็นการจำลองเชิงฟังก์ชัน: โปรแกรมถูกแบ่งออกเป็นงานอิสระที่สามารถเรียงลำดับหรือดำเนินการพร้อมกันได้

1. หมวดหมู่ของการประมวลผลพร้อมกัน

นักพัฒนาโดยทั่วไปเลือกระหว่างกลไกสามประการที่สำคัญเพื่อจัดการกับลำดับการทำงานพร้อมกันเหล่านี้:

กระบวนการ: การแยกตัวสูงด้วยพื้นที่หน่วยความจำที่แยกจากกัน; ต้องใช้การสื่อสารระหว่างกระบวนการ (IPC) ที่ถูกควบคุมโดยเคอร์เนล
การจัดการอินพุต/เอาต์พุตแบบหลายช่องทาง: ลำดับเดียวที่เปลี่ยนแปลงอย่างมีเจตนาระหว่างเหตุการณ์ที่พร้อมใช้งาน (เครื่องจักรสถานะ)
เธรด: ลำดับเบาบางที่แชร์พื้นที่หน่วยความจำเสมือนเดียวกันเพื่อให้การแลกเปลี่ยนข้อมูลทำได้ง่าย

2. การดำเนินการเชิงตรรกะ เทียบกับ การดำเนินการจริง

แม้ว่าจะทุก โปรแกรมที่ทำงานขนานกัน จะเป็นการประมวลผลพร้อมกัน แต่ไม่ใช่ทุกโปรแกรมที่ทำงานพร้อมกันจะเป็นการประมวลผลขนานกัน ความขนานกันคือการดำเนินการจริงของลำดับบนคอร์ฮาร์ดแวร์ที่แยกจากกัน การประมวลผลพร้อมกันคือการออกแบบเชิงตรรกะที่ทำให้การดำเนินการเหล่านั้นเกิดขึ้นได้

TERMINALbash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

Which concurrency model offers the highest level of isolation between flows?

Threads

I/O Multiplexing

Processes

Coroutines

QUESTION 2

A program is 'Parallel' only if its concurrent flows...

...are managed by the kernel.

...execute simultaneously on separate processor cores.

...use shared memory for communication.

...are triggered by I/O events.

QUESTION 3

What is a primary disadvantage of I/O Multiplexing compared to Threads?

High context-switch overhead.

Inability to exploit multi-core parallelism.

Difficulty in sharing global data.

Requirement for complex IPC mechanisms.

QUESTION 4

Why do modern windowing systems use concurrency for UI responsiveness?

To ensure memory safety.

To allow the interface to respond to user input while background tasks execute.

To prevent the kernel from reaping child processes.

To bypass the need for a file descriptor table.

QUESTION 5

In the taxonomy of concurrency, which model models the application as a state machine?

Process-based

Thread-based

I/O Multiplexing

Sequential programming

Deep Dive: Concurrency Architecture & Synchronization

Analysis of Process Management and Buffer Safety

Examine the mechanics of a concurrent server using process-based concurrency and the synchronization requirements of shared buffers in producer-consumer systems.

Figure 12.5 demonstrates a concurrent server in which the parent process creates a child process to handle each new connection request. Trace the value of the reference counter for the associated file table for Figure 12.5.

Solution:
The reference counter for the connected file descriptor table entry evolves as follows:
1. Initial: The parent accepts a connection, creating connfd. Reference count = 1.
2. Fork: The parent calls fork(). The child inherits the descriptor table. Reference count = 2.
3. Parent Close: The parent calls Close(connfd). Reference count = 1.
4. Child Termination: The child handles the request and exits (or calls Close). Reference count = 0, allowing the kernel to reclaim the socket.

Let $p$ denote producers, $c$ consumers, and $n$ the buffer size. Is the mutex semaphore in sbuf_insert/sbuf_remove necessary if (Scenario 1) $p=1, c=1$ and (Scenario 2) $p=1, c=10$?

Solution:
Scenario 1 ($p=1, c=1$): In a basic circular buffer where the producer only modifies the 'rear' and the consumer only modifies the 'front', a mutex is not strictly necessary for correctness, though often used for simplicity.
Scenario 2 ($p=1, c=10$): Yes, the mutex is mandatory. Because multiple consumers are competing to update the 'front' index and decrement the item count, a race condition would occur without mutual exclusion.

If the parent process in Figure 12.5 failed to close its copy of the connected descriptor, what specific resource leak occurs?

Solution:
This results in a file descriptor leak. Even if the child process exits and closes its copy, the reference count in the kernel's file table never reaches zero because the parent (which runs forever) still holds a reference. Eventually, the server will hit its limit for open files and fail to accept new connections.